A key feature of Business Intelligence (“BI”) applications (or “tools”) is the ability to present data with associated analytics, for which the general term “reporting” will be used throughout this document. The reporting tools vary in scope and function, but a popular use is the creation and presentation of “scorecards” or “dashboards,” which may be thought of in one example as a collection of queries arranged to provide summary information at a glance.
Various BI reporting tools may provide detailed reports to supplement the dashboards and/or scorecards, as well as predictive analytics capabilities that allow for some level of planning, leveraging data mining algorithms and other techniques. BI application developers generally create the dashboards and reports manually based on end-user requirements and using the end-user's BI tool of choice. The reports typically obtain data from a data warehouse that is often built and managed using separate ETL tools, although the data could come from any source and the approaches detailed below are not limited to a particular data source.
A data warehouse is a database used for generating reports and data analysis. To facilitate reporting and data analysis functions, data is often transformed and organized in star schemas within a data warehouse. Populating the data within the data warehouse is done via ETL (Extract, Transform, Load) operations, which requires that the data warehouse maintain, in addition to the current state of the data warehouse, information about the last incremental data extractions obtained from the source tables. ETL operations propagate incremental changes made at the source tables into the star schemas of the data warehouse. ETL operations may transform the data prior to loading the data into the data warehouse. Examples of such types of transformation include data cleansing, data standardization, surrogate key generation, surrogate key replacement, unit of measure conversion, and currency conversion.
While the reports enabled by a BI tool may provide end-users with some degree of flexibility in rearranging aspects of the report layout or getting different views of data (e.g., using different parameters or filters), the current development model requires non-automated communication between end-users and report developers, which can cause several latency-related issues. End-users generally do not understand the data warehouse models, and therefore need to wait for a skilled professional to translate their reporting requirements into an actual report. Further, if changes are made at the data source that impact the data model, or just to the data model, then current reports may break until manually edited. Also, end-users with multiple BI tools need reports that work with each of them, which can require manual creation of reports for each BI tool.